r? @jdno

rustbot has assigned @jdno.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

☔ The latest upstream changes (presumably #145077) made this pull request unmergeable. Please resolve the merge conflicts.

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

Ready for review. @zachs18 @Noratrieb @jieyouxu

Pls review @jieyouxu @zachs18 @Noratrieb , i have make all changes requested.

I don't support adding support for the Supm extension because of its nature. At least, support in std_detect (backend of std::arch::is_riscv_feature_detected is once rejected by @Amanieu because of this (cf. rust-lang/stdarch#1770).

This extension itself does not provide any instructions, CSRs or machine behavior constraints but only denotes existence of a platform-dependent facility to control pointer masking behavior. For instance, the Supm extension on Linux denotes prctl-based control but we can actually call prctl to probe pointer masking.

EDIT: I don't support unless it's truly necessary (e.g. for interoperability with other object files compiled for RVA23U64). Even in this case, I would like to hear your thoughts about this extension.

And I have a concern regarding adding (so much) supervisor-mode extensions despite being a Linux target (which normally means a user mode target).

I personally recommend starting from RVA23U64 (excluding RVA23S64) and discuss possibilities extending it later.

I don't support adding support for the Supm extension because of its nature. At least, support in std_detect (backend of std::arch::is_riscv_feature_detected is once rejected by @Amanieu because of this (cf. rust-lang/stdarch#1770).

This extension itself does not provide any instructions, CSRs or machine behavior constraints but only denotes existence of a platform-dependent facility to control pointer masking behavior. For instance, the Supm extension on Linux denotes prctl-based control but we can actually call prctl to probe pointer masking.

EDIT: I don't support unless it's truly necessary (e.g. for interoperability with other object files compiled for RVA23U64). Even in this case, I would like to hear your thoughts about this extension.

Here are my thoughts:

• Supm is mandatory in RVA23U64, so the rva23 target must support it.
• HWASAN in LLVM may support RISCV in future, which need Supm. It may impact pointer address handling in LLVM backend code generation, so it must be explicitly passed to LLVM. Supm offers functionality nearly identical to aarch64 TBI, HWASAN in LLVM for aarch64 detailed on this page.
• I think using a probe to detect this feature on OS is unrelated to whether this rva23 target should support it.

r? compiler_leads

@ZhongyaoChen Okay, for the "Supm" extension, that's convincing for me.

So, the remaining subjects I strongly oppose are RVA23S64 and its extensions (all new extensions starting with either Ss, Sh or Sv).

1. This new target seems a user mode target with std (requiring RVA23U64, not RVA23S64) and implementing RVA23S64-specific supervisor mode extensions should not be a part of this proposal.
2. Even if RVA23S64 extensions are necessary, we need:
   • Either new target or separate proposal (for existing bare-metal targets) and
   • Some additional supervisor extensions and implications (like "H", required by "Sha" but not implied from it). I'll review that in detail later.

@a4lg good point, changes applied.
RVA23S64 do need a separate kernel-level code target.

Hi, This PR has been open for two weeks. All changes requested applied.
@davidtwco @Amanieu Pls help move this PR forward. Thanks.

The problem with Supm is that it doesn't actually enable any instructions or features on its own, so it is rather meaningless. I therefore don't think we should expose it as a user-visible target feature. Additionally, I checked and LLVM currently doesn't make use of it at all internally. We may revisit this once LLVM actually makes use of the Supm feature.

The problem with Supm is that it doesn't actually enable any instructions or features on its own, so it is rather meaningless. I therefore don't think we should expose it as a user-visible target feature. Additionally, I checked and LLVM currently doesn't make use of it at all internally. We may revisit this once LLVM actually makes use of the Supm feature.

From my understanding, it's meant to be a constraint on the execution environment, right? So, that would mean the user environment needs to provide the pointer masking.

Maybe conformance with Supm could be as simple as a check tied to the target triple? For example, something in the riscv64a23-unknown-linux-gnu target specification checks for some form of pointer masking syscall or similar? Alternatively, it could just be implicit that any target triple rustc provides with a riscv64a23- prefix must have some form of pointer masking.

I'm deferring to your and LLVM's opinion on this, though.

The problem is that "some form of pointer masking" isn't actually enough information to actually do anything. It doesn't tell you how many bits are masked, how to enable/disable masking, etc.

As a sidenote:

1. Adding the support for the "Supm" extension changes object files (RISC-V attributes) to state that this extension is required on given object file.
2. But is it worth it?
   • For tools that read RISC-V ELF attributes would see the difference.
   • However, the Linux kernel does not care about it when loading an executable.
   • It's still an RVA23-compliant program even if we don't require the "Supm" extension (because RVA23 profiles constrain execution environment).
   • std does not have any functions that changes behavior depending on the "Supm" extension, making this extension irrelevant inside the standard Rust (without external crates).

So my personal questions are:

1. Does putting the "Supm" extension support in the RISC-V attributes help someone in the RISC-V ecosystem?
2. Does supporting the "Supm" extension helpful for pointer masking users (like external crate developers to control pointer masking behavior if any)?

The problem is that "some form of pointer masking" isn't actually enough information to actually do anything. It doesn't tell you how many bits are masked, how to enable/disable masking, etc.

@Amanieu

The pointer mask width is variable, depending on the virtual address width (Sv57, Sv48, Sv39), which represents the max, but a smaller width can be used in practice (e.g., Sv48 allows 16 bits, but we can only use 8 bits).

Additionally, this kernel patch specifies that userspace can enable/set/ask the number of mask/tag bits needed by the application using a syscall.

Additionally, I checked and LLVM currently doesn't make use of it at all internally. We may revisit this once LLVM actually makes use of the Supm feature.

Agreed.

But there's an extra issue: rva23u64 implies Supm support. In Rust, removing Supm but keeping rva23u64 is odd; passing rva23u64 to LLVM means Supm is needed, whether or not it's visible in Rust target features.

So my personal questions are:

Does putting the "Supm" extension support in the RISC-V attributes help someone in the RISC-V ecosystem?
Does supporting the "Supm" extension helpful for pointer masking users (like external crate developers to control pointer masking behavior if any)?

@a4lg Since LLVM doesn’t use Supm yet, sorry, these questions are unclear now.

The problem is that "some form of pointer masking" isn't actually enough information to actually do anything. It doesn't tell you how many bits are masked, how to enable/disable masking, etc.

Additionally, this kernel patch specifies that userspace can enable/set/ask the number of mask/tag bits needed by the application using a syscall.

This is what I meant about the Supm support being implicit inside Rust. The compiler itself doesn't do anything, like you said and the spec confirms, no machine instructions are output related to Supm. It's just a guarantee that whatever target environment is specified by the target triple supports pointer masking in some form.